One issue in the development of applications for international distribution is the ability to support different languages. Such support is often referred to as National Language Support or NLS. One technique that may reduce development time for applications is to provide a language independent program or template that is then combined with language specific information to provide the application in a specific language. Such a technique may reduce overall development time but may provide its own problems.
JAVA® (JAVA® is a trademark of SUN Microsystems) programs conventionally handle multi-language labels and graphics in web pages by maintaining property files in the “name-value” format. Each label is given a name using ASCII (readable text), and then is associated with the appropriate translation based on a given property file. This technique permits one set of programs to be written in a language independent or neutral format. The specific “Locale” (NLS specifier) is then used to select the correct property file via modifiers such as ResourceBundles.
As discussed above, one technique used to provide NLS in JAVA® applications is the ResourceBundle. ResourceBundles appeared in web technology in approximately 1999 in JAVA® version 1.1. At that time, NLS was not fully understood by developers, and as such, this implementation lacked very basic functionality. In particular, it should not be possible to specify an “encoding” for the data in a ResourceBundle. The rules of the JAVA® standard dictate that this must be the default ISO-8859-1 encoding (which actually means that the data is treated as 8-bit bytes without any encoding at all). This technique is functional for single byte Western European languages, but it may have drawbacks when applied to double byte languages, or even some single byte languages such as Arabic, Hebrew, and Tamil, among others.
In order to overcome this limitation, the JAVA® recommendation, (via SUN), for these languages is to use the Unicode hexadecimal standard, where every Unicode character is represented by six bytes of the form “\uxxxx”. This data is then translated using the JAVA® pre-compiler code where it is converted into 16 bit Unicode.
A potential drawback related to this method may result from the conversion of the translated text into an unreadable format. This conversion process would normally need to be accomplished in a development lab as part of the build process of an application, because those not specifically skilled in the art may find it difficult to decipher the coding. This technique, as such, is very inflexible and may require significant time and expense, not to mention development delays, if any changes are required in any of these translated labels.
ResourceBundles, however, are property files, which allow them to be “discovered” through the CLASSPATH variable definition and are very easily read and rendered into the appropriate form. Additionally, ResourceBundles have excellent techniques for selecting default files, where the specified NLS property file does not exist, or cannot be found. In particular, the ResourceBundles may use a hierarchical selection process based on file name of the property files.
Extensible Markup Language (XML) has been used as an alternative to ResourceBundles. XML may have one major advantage over ResourceBundles in that “encoding” can be specified for each XML file, usually as “UTF-8”. This is reasonable and feasible as long as the editor in use understands that “UTF-8” (for example, UnicEdit) data can be seen in the natural font and can be edited in the appropriate language, and then saved as “UTF-8” formatted data. This technique can overcome the problems associated with ResourceBundles, where the data, typically, must be rendered into an unreadable “\uxxxx” format.
XML may, however, have disadvantages in comparison to ResourceBundles in that the format may be difficult for translators to work with. ResourceBundles have a very easy, intuitive, format. XML also may require a significantly greater amount of JAVA® code to read, parse, and handle errors when compared to ResourceBundles. There also is, typically, no “Locale” and “default” implementation for selecting the correct property file. Also, there is, typically, no automatic way to find an XML file through the CLASSPATH variable setting.